1. Field of Invention
This invention relates generally to methods for controlling data flow in a Direct Access Storage Device (DASD) channel, and more specifically, to an efficient Count-Key-Data (CKD) DASD channel control system employing a Predictive Track Table.
2 Discussion of the Related Art
Use of Direct Access Storage Devices (DASDs) in a data processing system requires performance of certain Input/Output (I/0) functions. Data must be transferred between the DASD and the host processor. Such DASDs are often connected to a host processor through an I/O channel. The host Central Processing Unit (CPU) operating system initiates data transfer with a command to the I/0 channel. This shifts control to a series of Channel Command Words (CCW's) that are sent from the CPU over the channel to the DASD controller for effectuating data movement across the interface.
The channel forwards each CCW to the controller for a selected DASD. Once the channel passes a command to a particular controller, the command must be interpreted and the elements of the command must be executed by the DASD. The various functions of channel, controller and command interpretation can be integrated with the host processor or distributed between the host and the mechanical storage components of the DASD.
The DASD controller performs several functions, including the interpretation and execution of CCW's forwarded by a channel from the host CPU. Seek commands position a DASD access mechanism. Search commands cause comparison between data from main CPU storage and data stored on specified DASD areas. Write commands cause data to be transferred from main CPU storage to specified DASD areas. Read commands cause data copies to be transferred from DASD storage to main CPU storage and checked for validity.
Another important function of the DASD controller is the prescription of data storage format for the DASD. Such a format includes provisions for certain "non-data" information such as the track address, record address, and so forth. There are also unused spaces and error correction codes prescribed for the DASDs commonly encountered in widespread use.
Conventional track formats include an index point on each track of the recording surface indicating the physical beginning of the track. Also, on each track, there is normally one Home Address (HA) that defines the physical location of the track and the condition of the track. The HA normally contains the physical track address, a track condition flag, a cylinder number (CC) and a head number (HH). The combination of the cylinder number and head number indicates the track address is commonly expressed in the form CCHH. The HA contains the "physical" track address, which is distinguished from a "logical" track address. The physical and logical track addresses may differ for records stored in the DASD tracks.
The first record following the HA is commonly a track descriptor record, sometimes referred to as R0. One or more user data records follow R) on the track. The first part of each user record is an "address marker" that enables the controller to locate the beginning of the record when reading data from DASD. Each user record is commonly formatted in either a "count-data" (CD) or a "count-key-data" (CKD) format. The only difference between the CD and CKD formats is the presence of key fields and key length data in the CKD formatted record. Both are herein henceforth referred to as CKD records.
The CKD record consists of a count field, an optional key field and a variable-length data field. The typical count field is of the form CC (two bits of cylinder number), HH (two bytes of head number), R (one byte of record number), KL (one byte of key length), and DL (two bytes of data length). Thus, each CKD record is self-identifying. The CCHH in the count field (called "logical" CCHH) is typically the same as the cylinder and head numbers in the HA for the track containing the record (called "physical" CCHH), although not necessarily. Thus, a CKD track consists of the track header (HA and RO) followed by some number of CKD records. The CKD record numbers (R) may, but need not, increment along the track in a monotonic pattern of one, two, three, etc.
In the typical situation, user data is written or read in a data field of a CKD record in some track on some DASD. The channel specifies the device and the track within the device of interest. The channel may also specify the rotational position on the track from which to begin searching for the record having the data field to be read or written. This is accomplished by specifying a search parameter (five bytes in the form CCHHR) for use by the DASD controller to match against count fields in the track of interest. When the DASD controller finds a CKD record on the track with a count field that matches the search parameter, it then either reads or writes the corresponding data field, which is provided by the host through the channel for record writes. The fundamental feature of importance to this disclosure is that the disk controller is not permitted to read or write until it has verified the existence of a count field in the track that matches the channel search parameter. This means that a write command will force the channel to wait until the matching record is actually located on the rotating DASD medium. Of course, such a read wait state is reasonable because a CKD record cannot be read until located, but the only overriding reason for holding the CPU channel merely to locate the proper record for updating is to ensure error recovery.
The prior art is replete with methods for reducing and eliminating the host CPU wait states necessitated by DASD accesses for read and write. A DASD cache is a high-speed buffer store used to hold portions of the DASD address space contents in a manner that reduces channel wait states. In U.S. Pat. No. 4,603,380, Malcolm C. Easton, et al, disclose a method for DASD cache management that reduces the volume of database transfers between DASD and cache, while avoiding the complexity of managing variable length records in the cache. Easton et al, achieve this by forcing the starting point for staging a record to the beginning of the missing record and, at the same time, allocating and managing cache space in fixed length blocks.
Some DASD controllers known in the art, such as the IBM 3990 DASD controller, have some amount of relatively fast Non-Volatile Store (NVS) for storing records that have been written by the host system but not yet written to the DASD medium by the DASD controller. The NVS is additional to the high-speed cache buffer store commonly included in the typical disk controller. DASD controllers having both cache and NVS are said to perform "fast-write" operations.
A fast-write operation proceeds as follows. If a track record to be updated is already in cache (that is, a record count field is found in cache that matches the search parameters provided by the host computer), the cache copy of the record is updated in cache and another updated copy is made in NVS. The two copies of modified records are maintained for error recovery purposes to avoid single points of failure. After copying to NVS, the DASD controller returns a completion signal to the host system, freeing the host CPU to proceed with the next channel operation. Such an operation is called a "fast-write hit" and is completed well before the updated record is actually written to the DASD medium. At some later time, the DASD controller asynchronously destages the updated record to disk from the cache and then removes the record from both cache and NVS.
This explanation, made in terms of a single record, actually is better understood in terms of a single track. DASD controller cache memory is generally organized in fixed block sizes. Because a single track is often a fixed size while single records are not, the typical practice is to stage and destage data from cache to DASD and back again in single track increments.
With a "fast-write hit", the DASD controller can eliminate the disk access time from the channel write operation as perceived by the host CPU. The actual destage of the modified record from cache to disk can be accomplished at a more convenient time; for example, when the DASD controller is idle, or when there is other work to be done against the same track or cylinder as the one holding the modified record.
If the record to be updated was not originally located in cache, however, the "fast-write" operation becomes a "fast-write miss" and the DASD controller must then locate the record on a disk before releasing the channel. That is, a fast-write miss is treated as if there is no cache. After the disk controller locates the track, it must search the count fields of records in the track starting at any specified rotational position, and search for a matching count field. Once the matching count field is located, the DASD controller updates the corresponding data field on the DASD medium and, only then, returns a completion signal to the host CPU. The controller may also read the entire track into cache at the same time in anticipation of subsequent updates to records on the same track.
It will be appreciated that a "fast-write miss" is much slower than a "fast-write hit" because it includes a disk access delay as part of the response time seen by the host CPU. Thus, although the "fast-write" is a useful technique commonly used in DASD controllers to improve the performance of write operations from the host system, the effectiveness of this technique depends on the number of "fast-write hits". This is because the controller functions as slowly on a fast-write miss as it does without the fast-write capability. Thus, for applications exhibiting poor write-hit ratios, use of DASD controllers with fast-write capability will not materially improve DASD channel efficiency.
In U.S. Pat. No. 4,875,155, James L. Iskiyan, et al, disclose a cache and a DASD backing store in which CKD records are staged and destaged to provide a "fast-write" capability. Iskiyan, et al teach the use look-up tables for indicatinq whether cache record images are modified with respect to the DASD-stored versions of the same records. While the Iskiyan, et al technique improves the read and write access efficiency for a "fast-write" type of system, their technique does nothing to avoid the "fast-write miss" delays described above. There is a strongly felt need in the art for a technique that will make available the benefits of the "fast-write" caching scheme to applications exhibiting poor write-hit ratios. The related unresolved problems and deficiencies are clearly felt in the art and are solved by this invention in the manner described below.